Using logic-based approaches to explore system architectures for systems engineering

system and the procedure defined on the abstract system can be translated to apply to the candidate architecture because they share the same inputs and outputs. The limitation with using the abstract system concept is that it requires all potential architectures have the same interface to the environment. This works well for the excavator example because all potential architectures must be able to suitably actuate the excavator’s digging arm and always connect to the digging arm in the same locations regardless of the structure of the alternative. If an even broader space of architectures is 87 considered, the question becomes whether such a system boundary could be defined for that entire space. One option is to include a union of all potential interfaces as part of the abstract system and then each architecture could realize only the appropriate interfaces. The problem with this approach is that some of the interfaces would be left unrealized and tests that reference those interfaces could potentially be incorrectly specified for those architectures. Another option is to redraw the abstract system to include only common interfaces. This would require some refactoring of the boundary definition, but it seems like the more promising option. The tests are defined in SysML using two very different formalisms. The structure of a test is defined using SysML Blocks along with the relevant constructs that usually appear on block definition or internal block diagrams. The procedure for the test is defined using UML activities. Since multiple tests may use the same structure and vary only in the process definition, the test structure can be defined in a reusable way using a test context. Then, any test using the same structure can specialize the test context and inherit this structure. This structure can also be slightly redefined as necessary using SysML’s redefinition constructs. To define the test procedure, a SysML activity is created which encompasses the entire procedure. SysML actually supports multiple formalisms which would be suitable for defining the test’s behavior, but the activity formalism was chosen because it seems to be the most intuitive to designers and also because constructs exist to relate the activity elements to the test context. The SysML activity is defined to be the classifier behavior of a particular test. In the activity, the procedure of the test is defined using various actions. The activity formalism also has primitive actions that are included in SysML and derived from UML.